The present invention is generally directed to computer operating systems and the management of system resources. More particularly, the invention is related to structures and management of virtual memory address spaces in a manner to reduce operating system overhead and to reduce the need for operator or operator substitute real time management of initiators. Additionally, the invention provides a mechanism for establishing and managing a pool of address spaces which are at least partially tailorable to specific operating system requests.
In a computer system having virtual memory capabilities and an operating system, it is necessary to isolate users from one another. A significantly useful mechanism for this purpose is the concept of an address space which represents the total amount of memory available to a user, it being understood that not all of the user's data is physically present in the main computer memory at any one instance of time. Rather, in accordance with well known virtual memory methods, different blocks of the user's data and/or program information are swapped in and out of main memory from slower memory devices, typically direct access storage devices.
For example, users of the time Sharing Option (TSO) of the MVS Operating System, developed and marketed by the assignee of the present invention, are in fact assigned a special address space for their transaction and programming needs every time such a user logs on to such a computer system. However, there is a significant amount of system overhead and administrative operations that must be performed in order to establish such an address space assigned to a particular user and having certain characteristics. It is this undesirable overhead which is reduced by the structures and processes employed in the present invention.
With respect to the MVS Operating System, there are two job entry subsystem (JES) means available for creating the address spaces assigned to specific users. Such address spaces are referred to as initiators in both the JES2 and JES3 environments. In the JES2 environment, operators have to start initiators using a specific command. Each initiator must be defined to a specific class or set of classes (see below for the discussion of what constitutes a class). The class is typically specified by the user by means of a job control language (JCL) statement submitted with the user's work. If the work submitted by the user is to run in class T, for example, and there are no class T initiators available, the work submitted by the user is not run until an initiator is started for this class. Initiators which are idle in other classes cannot be used.
In the JES3 Operating System environment, the manager of the computer installation, typically through a systems programmer, can define a job class group using the GROUP statement available for defining installation controls. The job control language material submitted by the user with the programs to be run associates it with a group containing one or more classes. For purposes herein, the group and class designations can be considered to be synonymous. For example, in JES3 each GROUP statement defines the characteristics of the group. That is, it specifies what devices are needed, the number of initiators to be dedicated to the group, and what processors the initiators are to run on. Initiators are dedicated to a group and cannot be used for scheduling any other job class group.
Initiator address spaces can also be created through an MVS START command. This method of starting an initiator is used by the Time Sharing Option (TSO) of the MVS Operating System, as mentioned above and is also used by system operators to start programs called "started tasks", in the new address spaces. These are sometimes called demand initiators and they result in the guaranteed start of an initiator address space bound to the specific work unit for which it was created. This work unit may be the specific task started or the particular user who has logged on to the system. The work unit does not wait beyond the time required to start the initiator address space. That is to say, the work started in this way is not really queued for execution. Additionally, the initiator started in this manner cannot be used for scheduling any other class or individual work unit.
It should be appreciated from the above that, there has been no automation or flexibility in the creation and allocation of initiator address spaces. Accordingly, computer system installation managers, system programmers and system operators have experienced the chore of managing initiator address spaces either individually or by class or group. Additionally, it has been difficult to specify response time goal and range information for the management of initiator address spaces. Thus, it is possible at various times in a computer installation to have either too few or too many initiator address spaces defined. If too few initiator address spaces are in existence, then new work coming into the system repeatedly requires the creation of such address spaces or the work waits until an existing and eligible initiator completes a previous unit of work. Likewise, the termination of such work can often trigger the destruction of initiators or lend to excessive idle initiators unable to process other work. Since the formation of new initiator address spaces consumes relatively large amounts of system overhead time, it should be clearly appreciated that the repeated creation and destruction of such spaces represents a non-optimal utilization of computer system resources. Likewise, if too many initiators are created and defined, then system resources are also unnecessarily consumed. This could have a negative impact on throughput and performance of other tasks and jobs being performed by the system whose memory resources are diminished by the excessive number of initiators in existence. Additionally, it is seen that initiators have not heretofore been reused for different classes of work than those to which they were originally bound (assigned).